The present invention relates to drivers for computers and in particular, though not necessarily, to drivers for interfacing input/output devices of a computer with software applications running on the computer.
The Microsoft Windows 95 and NT (Trade Marks) operating systems have established themselves as the dominant operating system for personal computers (PC). Furthermore, it can be expected that in the near future derivatives of the Windows ((trademark)) systems will continue to hold this position. As such, designers of software applications intended to run on PCs are to a great extent constrained by the need to enable their applications to run under the Windows ((trademark)) operating system.
In addition to the basic software xe2x80x98kernelxe2x80x99, which provides the base operating system (including file i/o services, memory management, and task scheduling), Windows 95 and NT ((trademark)) comprise a User component (USER.EXE) which allows applications to be interfaced to internal and external devices such as hard disc drives, memory chips, and input/output ports. This architecture is used so that all applications can use a common input/output protocol regardless of the input/output (i/o) device with which they are communicating. It is the interface modules which handle xe2x80x98translationxe2x80x99 of the common protocol into i/o device specific protocols and vice versa.
The central communications component of Windows 95 (Trade Mark) is the virtual communications driver or module VCOMM which manages access to xe2x80x98comxe2x80x99 ports and printer ports. These ports require a single asynchronous data stream and are in fact xe2x80x98virtualxe2x80x99 ports defined by an actual physical port in combination with a virtual device driver (VxD) termed a xe2x80x98port driverxe2x80x99. Upon installation, Windows 95 creates a com port for each physical serial port of the computer. Typically there are two such physical ports giving rise to com ports xe2x80x98Com1xe2x80x99 and xe2x80x98Com2xe2x80x99. Other (virtual) com ports may be added as required. Corn ports may be selected from the xe2x80x98Systemxe2x80x99 window in the xe2x80x98Control Panelxe2x80x99. VCOMM is also present in Windows 3.11 and can be installed in Windows 3.1.
WO 96/35286 describes a mobile telephone coupled to a personal computer and more particularly a software program for operating the phone through an i/o port of the computer. This port may be a serial port or a parallel port, e.g. PCMCIA. The controlling application in such a system may be, for example, the WinFax ((trademark)) application which enables facsimiles to be written on the computer and transmitted via the connected phone. The application also enables incoming facsimiles to be received on the computer. WinFax is able to communicate with the phone through VCOMM and a standard virtual serial port (i.e. a physical port in combination with a serial VxD customised for the phone) registered to VCOMM. This virtual port is typically installed as xe2x80x98Com3xe2x80x99.
In the case of the mobile telephone coupled to a computer, it is extremely desirable to be able to monitor the status of the phone, e.g. call in progress, incoming call received etc, via the computer and to be able to provide a visual indication of that status on the computer""s display. This is especially so where the phone has no user interface and is intended solely for use with a computer. To achieve this monitoring, it is possible to run a custom monitoring application on the computer which is interfaced with the phone through VCOMM and a virtual port.
It is also extremely desirable to be able to run a monitoring application of the type described above at the same time as another application, e.g. WinFax, is being used to control the connected telephone. However, as the same virtual port cannot be used for both applications, this requires the installation of two additional com ports (e.g. Com3 and Com4) although both com ports share the same VxD. The resulting large number of com ports appearing on the xe2x80x98Systemxe2x80x99 Control Panel is likely to confuse the user and may result in com ports being incorrectly registered by the user.
A possible solution to this problem is to interface the control application (e.g. WinFax) to the phone using VCOMM and to interface the monitoring application through another Windows ((trademark)) communications module known as DeviceIOcontrol. DeviceIOcontrol is a more primitive interface than VCOMM but is well suited to relatively simple applications. The virtual serial port registered to DeviceIOcontrol for the monitoring application will not appear on the System Control Panel and only Com3, registered to WinFax, will appear there.
In order to minimise the space occupied by the two additional virtual ports in RAM, both ports should utilise the same VxD. However, a problem arises when DeviceIOcontrol attempts to register the phone specific VxD after the control application has previously registered that same VxD. Upon first registration, VCOMM loads the VxD from the computer""s hard disc into random access memory (RAM). The address at which a registration table can be found is also provided to VCOMM, which table contains the location of VxD functions which can be called by VCOMM. When DeviceIOcontrol subsequently tries to register with the VxD, it finds that the VxD has already been loaded to RAM and the address of the registration table (and any other necessary information) is not provided to DeviceIOcontrol. DeviceIOcontrol is therefore unable to communicate with the telephone.
It will be appreciated that this problem arises wherever two or more applications are required to access the same i/o device, with the same VxD, but using different communications modules.
It is an object of the present invention to overcome or at least mitigate the problems noted in the preceding paragraphs. This and other objects are met by providing a main driver for the i/o device, and two or more supplementary drivers which can be registered with respective communications modules.
Upon registration of a supplementary driver, that driver registers the main driver to the associated communications module, loading the driver to RAM memory if this has not already been done. Regardless of whether or not the main driver has already been loaded however, the supplementary driver provides the main driver function interface to the associated communications module.
According to a first aspect of the present invention there is provided a method of operating a computer having a non-volatile memory, a random access memory (RAM), at least one input/output (i/o) device, and an operating system in which at least two communications modules are provided for interfacing applications running on the computer to said i/o device, the method comprising:
registering a first supplementary driver to a first of the communication modules, whereupon the first supplementary driver causes a main driver, which defines the communications protocol for said i/o device, to be loaded from the non-volatile memory to the RAM and also transfers a function interface for the main driver to said first communications module; and
subsequently registering a second supplementary driver to a second of the communication modules, whereupon the second supplementary driver transfers a function interface for said main driver to said second communications module.
Preferably, said operating system is a Windows ((trademark)) operating system, for example Windows 95, and the two communications modules are VCOMM and DeviceIOcontrol.
The term xe2x80x98i/o devicexe2x80x99 is used here to denote a receiver and/or generator of digital data. The device may be for example a physical i/o port in combination with a physical device, an internal memory unit, or a software module.
In one embodiment, said i/o device comprises a serial interface port, e.g. an RS232 port. More preferably, said communications protocol is a protocol for communicating with a mobile telephone coupled to a serial interface port of the computer. Alternatively, the i/o device may comprise a parallel port, e.g. a PCMCIA slot.
Preferably, said function interface which is transferred to the communications modules comprises the address of a registration (or main driver access address) table.
According to a second aspect of the present invention there is provided a storage medium having recorded thereon at least said first and second supplementary drivers of the above first aspect of the invention.
Preferably, the storage medium also has recorded thereon said main driver.
According to a third aspect of the present invention there is provided a computer programmed to perform the method of the above first aspect of the invention.
According to a fourth aspect of the present invention there is provided a computer having a non-volatile memory, a random access memory (RAM), at least one input/output (i/o) device, and an operating system in which at least two communications modules are provided for interfacing applications running on the computer to said i/o device, the computer comprising:
a main driver stored in the non-volatile memory and defining the communications protocol for said i/o device;
a first supplementary driver for registration to a first of the communication modules, the first supplementary driver being arranged in use to cause the main driver to be loaded from the non-volatile memory to the RAM and also to transfer a function interface for the main driver to said first communications module; and
a second supplementary driver for registration to a second of the communication modules, the second supplementary driver being arranged to transfer a function interface for said main driver to said second communications module.
Preferably, said operating system is a Windows ((trademark)) operating system, and said communications modules are VCOMM and DeviceIOcontrol.
Preferably, said i/o device is a mobile telephone coupled to a serial interface port of the computer.